Over the past several years, computer server functionality has become increasingly modular. The rise of transaction processing, web services, eXtensible Markup Language (“XML”) interfaces, and similar technologies has resulted in a situation in which a lengthy execution chain involving one or more application servers, middleware servers, database servers, and/or the like, merely to service a single user request (e.g., an hypertext transfer protocol (“HTTP”) GET request from a web browser).
This modularity provides several benefits. For one thing, such modularity allows an application developer to focus on providing a best-of-breed application to handle a single task, confident in the ability of that application to send and receive messages (or other data) with other applications in a standardized format, such as the Simple Object Access Protocol (“SOAP”), the XML Information Bus, the Java Messaging Service (“JMS”), and HTTP messages, to name a few examples. Accordingly, an application developer need not concern itself with building a “soup-to-nuts” solution to solve a particular computing need. Further, this modularity provides far more extensible and maintainable solutions than older, monolithic applications.
This modularity, however, has greatly complicated the task of software instrumentation and performance monitoring. For example, in an execution chain involving several different application components, it can be difficult to monitor the performance (and/or even confirm the execution) of a particular application component to determine, for example, which component is introducing performance bottlenecks and/or preventing the execution chain from completing successfully.
Separate application monitoring frameworks tend to require recoding of the entire application chain to accommodate the monitoring framework, making such solutions both expensive and difficult to integrate with existing solutions. Moreover, such frameworks tend to impose their own performance penalties on the monitored applications, because of the processing overhead required to perform the monitoring.
Thus, there is a need for a lightweight application execution- and performance-monitoring framework. It would be beneficial if such a framework could be implemented in existing environments without requiring extensive application recoding. It would also be beneficial if such a framework could operate without undue impact to the performance of the monitored applications and/or could provide end-to-end monitoring of execution chains.